In computer storage, a volume management scheme provides a method of allocating space on mass-storage devices that is more flexible than conventional partitioning schemes. In particular, a volume manager can concatenate, stripe together or otherwise combine partitions into larger virtual units that administrators can re-size or recreate, potentially without interrupting system use. Supporting backups for a high-density file system using traditional mechanism of walking through the files and collecting information can often be very slow. Snapshot techniques, such as the Networker SnapImage Module solve this problem by taking snapshot images of the file system to perform live backups at the block level. Unlike disk-level backup systems, resizing or recreating a volume requires block-level snapshot programs like SnapImage to track and accommodate any resizing or recreation of blocks to ensure proper backup operation.
Backup applications supporting block-level incremental backup are built upon tracking writes onto volumes. The UNIX volume manager creates volume devices conforming to standards making a block and or character device for each volume it creates. Each block/character device is represented using a major and minor number. To track writes to the volume, the snapshot program creates a bitmap indexed using major and minor number of the volume device. The length of the bitmap is directly proportional to the size of volume. The change in size of volume needs to be tracked so that the bitmap can be adjusted accordingly. Volume manager programs usually provide a user interface that allows deletion and re-creation of the same volume. Administrators may re-create volumes for number of reasons, such as changing the disk layout from concatenated to striped, or vice versa. Re-creation or re-sizing of a volume may result in a new pseudo volume device with a minor number that may have been previously used. Any such repetition must be tracked and reported to the snapshot backup application so that the bitmap created for that volume can be flushed or recreated. If any repetition of the major/minor number is not tracked, the snapshot program may perform an incomplete or incorrect backup.
In present backup systems, the change in length or recreation of a volume is not tracked as the bitmap created within most snapshot programs tracks writes on the low level disk. Thus, present backup systems fail to accommodate challenges posed by resizing or recreation of volumes at the block-level. There is a need, therefore, for an improved method or system to track re-sizing and re-creation of volumes.